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       The Secure Neighbor Discovery (SEND) Hash Threat Analysis

Abstract

   This document analyzes the use of hashes in Secure Neighbor Discovery
   (SEND), the possible threats to these hashes and the impact of recent
   attacks on hash functions used by SEND.  The SEND specification
   currently uses the SHA-1 hash algorithm and PKIX certificates
   and does not provide support for hash algorithm agility.  This
   document provides an analysis of possible threats to the hash
   algorithms used in SEND.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any
   errata, and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6273.
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   Copyright (c) 2011 IETF Trust and the persons identified as the
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   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
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1.  Introduction

   SEND [RFC3971] uses the SHA-1 hash algorithm [SHA1] to generate the
   contents of the Key Hash field and the Digital Signature field of the
   RSA Signature option.  It also indirectly uses a hash algorithm
   (SHA-1, MD5, etc.) in the PKIX certificates [RFC5280] used for router
   authorization in the Authorization Delegation Discovery (ADD)
   process.  Recently there have been demonstrated attacks against the
   collision free property of such hash functions [SHA1-COLL] and
   attacks on the PKIX X.509 certificates that use the MD5 hash
   algorithm [X509-COLL].  The document analyzes the impacts of these
   attacks on SEND and it recommends mechanisms to make SEND resistant
   to such attacks.
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2.  Impact of Collision Attacks on SEND

   [RFC4270] summarizes a study that assesses the threat of the
   aforementioned attacks on the use of cryptographic hashes in Internet
   protocols.  This document analyzes the hash usage in SEND following
   the approach recommended by [RFC4270] and [NEW-HASHES].

   The following sections discuss the various aspects of hash usage in
   SEND and determine whether they are affected by the attacks on the
   underlying hash functions.

2.1.  Attacks against CGAs Used in SEND

   Cryptographically Generated Addresses (CGAs) are defined in [RFC3972]
   and are used to securely associate a cryptographic public key with an
   IPv6 address in the SEND protocol.  Impacts of collision attacks on
   current uses of CGAs are analyzed in [RFC4982].  The basic idea
   behind collision attacks, as described in Section 4 of [RFC4270], is
   on the non-repudiation feature of hash algorithms.  However, CGAs do
   not provide non-repudiation features.  Therefore, as [RFC4982] points
   out CGA-based protocols, including SEND, are not affected by
   collision attacks on hash functions.  If pre-image attacks were to
   become feasible, an attacker can find new CGA Parameters that can
   generate the same CGA as the victim.  This class of attacks could be
   potentially dangerous since the security of SEND messages relies on
   the strength of the CGA.

2.2.  Attacks against PKIX Certificates in Authorization Delegation
      Discovery Process

   To protect Router Discovery, SEND requires that routers be authorized
   to act as routers.  Routers are authorized by provisioning them with
   certificates from a trust anchor, and the hosts are configured with
   the trust anchor(s) used to authorize routers.  Researchers
   demonstrated attacks against PKIX certificates with MD5 signatures in
   2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007] [SLdeW2007], and in
   2009 [SSALMOdeW2009] [SLdeW2009].  An attacker can take advantage of
   these vulnerabilities to obtain a certificate with a different
   identity and use the certificate to impersonate a router.  For this
   attack to succeed, the attacker needs to predict the content of all
   fields (some of them are human-readable) appearing before the public
   key, including the serial number and validity periods.  Even though a
   relying party cannot verify the content of these fields, the CA can
   identify the forged certificate, if necessary.
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2.3.  Attacks against the Digital Signature in the SEND RSA Signature
      Option

   The digital signature in the RSA Signature option is produced by
   signing, with the sender's private key, the SHA-1 hash over certain
   fields in the Neighbor Discovery message as described in Section 5.2
   of [RFC3971].  It is possible for an attacker to come up with two
   different Neighbor Discovery messages m and m' that result in the
   same value in the Digital Signature field.  Since the structure of
   the Neighbor Discovery messages is well defined, it is not practical
   to use this vulnerability in real world attacks.

2.4.  Attacks against the Key Hash Field of the SEND RSA Signature
      Option

   The SEND RSA signature option described in Section 5.2 of [RFC3971]
   defines a Key Hash field.  This field contains a SHA-1 hash of the
   public key that was used to generate the CGA.  To use a collision
   attack on this field, the attacker needs to come up with another
   public key (k') that produces the same hash as the real key (k).  But
   the real key (k) is already authorized through a parallel mechanism
   (either CGAs or router certificates).  Hence, collision attacks are
   not possible on the Key Hash field.  Pre-image attacks on the Key
   Hash field are not useful for the same reason (any other key that
   hashes into the same Key Hash value will be detected due to a
   mismatch with the CGA or the router certificate).

3.  Conclusion

   Current attacks on hash functions do not constitute any practical
   threat to the digital signatures used in SEND (both in the RSA
   signature option and in the X.509 certificates).  Attacks on CGAs, as
   described in [RFC4982], will compromise the security of SEND and they
   need to be addressed by encoding the hash algorithm information into
   the CGA as specified in [RFC4982].

4.  Security Considerations

   This document analyzes the impact that the attacks against hash
   functions have on SEND.  It concludes that the only practical attack
   on SEND stems from a successful attack on an underlying CGA.  It does
   not add any new vulnerabilities to SEND.
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